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(57) Abstract 

A method for facilitating communication between 
a first person (e.g., account holder (35)) and a second 
person (e.g., a user) so that the first person (35) may 
authorize a transaction between the second person and 
a third party (e.g., a merchant (10)). The method com- 
prises the steps of linking the first (35) and second per- 
sons to a financial account that is used for the trans- 
action, receiving data identifying the financial account 
and the third party (10) from the third party (10), inquir- 
ing whether the first person (35) desires to communicate 
with the second person based on the data identifying the 
financial account, and enabling communication between 
the first (35) and second persons based on a response to 
the inquiry from the first person (35) and the data iden- 
tifying the third party (10). In this way, the first person 
(35) controls the authorization or denial of a transaction 
executed by a user based on circumstances surrounding 
the transaction. 
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METHOD AND SYSTEM FOR CONTROLLING 
AUTHORIZATION OF CREDIT CARD TRANSACTIONS 



FIELD OF THE INVENTION 

5 The present invention enables a first person who holds a credit card 

account to control a second person's use of a credit card that is linked to the account. 
More specifically, this invention relates to a method and system for enabling the first 
person to communicate with the second person who is using the credit card to execute a 
transaction with a merchant and for allowing the first person to authorize or decline the 
1 0 transaction based on the communication. 



BACKGROUND OF THE INVENTION 

A bank or other issuer issues credit cards having corresponding credit 
card accounts to individuals (hereafter, "account holders"). A credit card account 
1 5 typically has a credit line associated therewith, which indicates a maximum monetary 
amount that may be charged to the account. An account holder may use his credit card 
to purchase goods and/or services (collectively, "goods") from one or more merchants 
in an aggregate amount that may not exceed the credit line for the account. 

It is common for an account holder to permit another person (hereafter, 
20 "user") to purchase goods using a credit card that is linked to the account holder's 
account. When doing so, however, it is possible that the user may abuse privileges 
afforded by the credit card and thus may embark on a frivolous and costly spending 
spree for which the account holder is ultimately responsible. 

The potential for such abuse is readily apparent in the case in which a 
25 parent permits a child to purchase goods using a credit card that is linked to the parent's 
account. The parent may attempt to curtail the potential abuse by providing guidelines 

1 
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to the child concerning appropriate uses of the credit card. Thus, the parent may instruct 
the child that the credit card is to be used only in cases of "emergency." However, for 
any number of reasons, such guidelines and instructions may be insufficient to prevent 
the abuse. For example, the parent's definition of an "emergency" may differ greatly 
from that of the child's thus resulting in charges to the credit card that would be deemed 
inappropriate by the parent. 

Parents and other account holders are currently limited in their ability to 
control and manage charges made by users using credit cards that are linked to their 
accounts. While certain known techniques endeavor to provide adequate control, they 
suffer from significant problems. 

For example, First Bank's "Corporate Relocation Card" service allows an 
employee to use a credit card that is linked to an employer's account. It is intended that 
the employee will use the credit card to pay for certain types of expenses - i.e., those 
necessary for relocation. Due to the potential for abuse by an employee, the employer is 
permitted to control the types of expenses that the employee may charge to the credit 
card. 

To do this, the employer designates certain classes of merchants (by 
Standard Industrial Classification ("SIC") code and/or Merchant Category Code 
("MCC")) from which an employee may not purchase goods. The SIC code and/or 
MCC are associated with the credit card account in First Bank's database so that 
transactions for which a designated SIC code or MCC is received during the 
conventional transaction authorization process are declined. 

United States Patent No. 4,873,422 to Dethloff entitled "Multi-User Card 
System" discloses a programmable card that is issued to a cardholder. The card can be 
programmed by the cardholder for use by a sub-user. The system allows the cardholder 
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to set criteria by which the sub-user may use the card — e.g., a maximum amount of 
money that can be charged to the card and/or a time period in which the sub-user may 
use the card. In this way, the cardholder is able to gain some control over the ways in 
which the sub-user may use the card. Although the First Bank service and the Dethloff 
5 patent each provide an account holder with some ability to control a card-based 

transaction executed by a user, they do not permit an account holder to exercise this 
control remotely and based on circumstances surrounding the transaction. 



For Non-Cash Transactions 11 discloses a system and method in which an owner of a 

10 credit card is notified when the credit card is used for a transaction. According to this 
patent, if a transaction is "illegal" (e.g., executed by someone other than the owner or is 
of a particular type), then the owner may use a telephone and contact the credit card 
issuer to stop the transaction. The Wong patent, however, does not enable 
communication between the owner and the person executing the transaction. 

15 United States Patent No. 5,655,007 to McAllister entitled "Telephone 

Based Credit Protection" teaches a technique for verifying the identity of a cardholder. 
According to the McAllister patent, a conventional credit card authorization process is 
initiated by a merchant and suspended by a credit card issuer who is verifying the 
transaction. At the point-of-sale, a voice sample of the cardholder is taken and is 

20 transmitted via telephone to the credit card issuer's system. The credit card issuer's 

system matches the voice sample taken from the cardholder at the point-of-sale with a 
pre-recorded digital voice sample that was taken at an earlier time. If the two voice 
samples match, then the credit card issuer may authorize the transaction, assuming that 
the other criteria relating to conventional transaction authorization processing are met. 

25 Thus, the McAllister patent teaches a way to increase the security of transaction 



United States Patent No. 5,615,1 10 to Wong entitled "Security System 
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executed by a cardholder, but fails to teach a way for a cardholder to remotely control 
transactions executed by another user of the credit card. 

In view of the above, a substantial need exists for a method and system 
in which an account holder can communicate with a user executing a card-based 
5 transaction and remotely control the authorization or denial thereof contemporaneous 
with and based on circumstances surrounding the transaction. 



4 
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SUMMARY OF THE INVENTION 



A first aspect of the present invention is directed to a method for 



facilitating communication between first person (e.g., an account holder) and a second 
person (e.g., a user) so that the first person may authorize a transaction between the 
5 second person and a third party (e.g., a merchant). The method comprises the steps 
of linking the first and second persons to a financial account that is used for the 
transaction, receiving data from the third party identifying the financial account and 
the third party, inquiring whether the first person desires to communicate with the 
second person based on the data identifying the financial account, receiving a 
10 response to the inquiry, and initiating communication between the first and second 
persons based on the response. 



communication between first and second persons so that the first person may 
authorize a transaction between the second person and a third party. The method 

1 5 comprises the steps of linking the first and second persons to a financial account that 
is used for the transaction, receiving data identifying the financial account and the 
third party from the third party, accessing a database based on the data identifying the 
financial account to determine a telephone number of the first person, and placing a 
telephone call to the first person based on the telephone number thereof, and inquiring 

20 whether the first person desires to communicate with the second person. If the first 
person responds affirmatively to the inquiry, a database is accessed based on the data 
identifying the third party to determine a telephone number thereof and telephonic 
communication is enabled between the first and second persons using the telephone 
number of the third party. 



A second aspect of this invention is directed to a method for facilitating 
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A third aspect of the present invention relates to a method for 
facilitating communication between an account holder and a user so that the account 
holder may authorize a card-based transaction between the user and a merchant. The 
method includes the steps of linking the account holder and the user to a financial 

5 account associated with the card that is used for the transaction, wherein the financial 
account is identified by an account number. The method further includes the steps of 
communicating with the third party to receive the account number and data identifying 
the third party, accessing a first database based on the account number to determine a 
telephone number of the first person, and attempting to contact the first person using 

10 the telephone number thereof. When the attempt to contact the first person is 

successful, an inquiry is made as to whether the first person desires to communicate 
with the second person. In response to an affirmative answer to the inquiry from the 
first person, a second database is accessed based on the data identifying the third 
party to determine a telephone number thereof and telephonic communication is 

15 enabled between the first and second persons using the telephone number of the third 
party. 

A fourth aspect of this invention is directed to an apparatus for 
facilitating communication between a first person at a first location and a second 
person at a point-of-sale location so that the first person may authorize a transaction 
20 between the second person and a third party at the point-of-sale location, wherein the 
first and second persons are linked to a financial account used for the transaction. 
The apparatus includes a memory storing data identifying the financial account and 
the third party, a first telephone number associated with the first location, and a 
second telephone number associated with the point-of-sale location. 



6 
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The apparatus also includes a processor in communication with the 
memory. The processor is adapted and configured to receive the data identifying the 
financial account and the third party from the third party, access the memory based on 
the data identifying the financial account and the third party to determine the first and 
5 second telephone numbers, transmit instructions to contact the first person based on 
the first telephone number, inquire whether the first person desires to communicate 
with the second person, and enable communication between the first and second 
persons based on a response to the inquiry and the second telephone number. 



7 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Representative embodiments of the present invention will be described 
with reference to the following figures: 

FIG. 1 is a schematic illustration of an apparatus for facilitating 
5 communication between first and second persons so that the first person may 
authorize a transaction between the second person and a merchant. 

FIG. 2 is a diagrammatic representation of a server of the apparatus of 

FIG. 1. 

FIG. 3 illustrates a credit card account database of the server of the 
1 0 apparatus of FIG. 2. 

FIG. 4 illustrates a merchant database of the server of the apparatus of 



20 



FIG. 2. 



FIG. 5 illustrates a user database of the server of the apparatus of FIG. 2. 
FIG. 6 illustrates a transaction database of the server of the apparatus of 



15 FIG. 2. 



FIGS. 7 A and 7B illustrate a process for processing a credit card 
transaction and for facilitating communication between first and second persons so that 
the first person may authorize a transaction between the second person and a merchant. 



DETAILED DESCRIPTION OF 
THE PREFERRED EMBODIMENTS 



Reference is now made to the accompanying Figures for the purpose of 
describing, in detail, the preferred embodiments of the present invention. The Figures 
25 and accompanying detailed description are provided as examples of the invention and 
are not intended to limit the scope of the claims appended hereto. 



8 



WO 99/45693 




PCT/US99/04892 



In accordance with the present invention, an account holder (or other 
authorized person) may permit a user to execute transactions with (i.e., purchase goods 
from) a merchant using a credit card that is linked to the account holder's credit card 
account. As used herein, a credit card is deemed to be "linked" to an account if a 
5 transaction involving the credit card affects the balance of the account. 

The invention allows the account holder to exercise control over the 
user's use of the credit card based on circumstances surrounding the transaction. This is 
achieved by enabling communication between the account holder and the user so that 
the account holder can determine the circumstances surrounding the transaction. For 

10 example, in an embodiment in which a parent permits a child to use a credit card only in 
emergency situations, the parent can communicate (e.g., telephonically) with the child 
to ascertain the nature of the emergency. In this way, the account holder can choose to 
authorize or decline the transaction based on the communication so as to effectively 
exercise control over the user's use of the credit card. 

1 5 FIG. 1 is a schematic illustration of a system for facilitating 

communication between an account holder and a user so that the account holder may 
authorize a transaction between the user and a merchant. In this embodiment, the 
account holder is a parent who maintains a credit card account with an issuer. The 
user is a child of the parent that uses an identifier that is linked to the parent's 

20 account. Of course, in alternate embodiments an account holder may be any 

individual or organization who maintains a credit card account with an issuer and a 
user may be any individual or organization that uses a credit card that is linked to the 
account. 

Merchant 10 is a business with whom a user executes a transaction — 
25 i.e., uses a credit card to purchase goods. Merchant 10 facilitates transactions at a point- 
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of-sale by using a card authorization terminal ("CAT") 15, such as those well known 
in the art, for transmitting a purchase authorization request to server 30. As is well 
known in the art, a purchase authorization request includes data indicating a purchase 
amount for the goods, an identifier that identifies a credit card that the user is presenting 

5 for payment, an identifier that identifies a merchant 1 0, and an identifier that identifies 
CAT 15 from which the purchase authorization request is transmitted. 

Merchant 10 also has a telephone 20 that is accessible by a user. In 
this embodiment, telephone 20 is located at the point-of-sale and is in close proximity 
to CAT 15. In this way, a user can have unfettered access to telephone 20. Of 

10 course, other communications devices such as a computer may be readily substituted 
for CAT 15 and/or telephone 20 without departing from the spirit and scope of the 
present invention. For example, CAT 15 and telephone 20 may be combined in a 
single device such as the combination CAT/telephone disclosed in United States 
Patent No. 3,793,624, the disclosure of which is incorporated herein by reference. 

15 CAT 15 and telephone 20 are in communication with 

telecommunications network 25 via lines 15A and 20A, respectively. In this 
embodiment, telecommunications network 25 is the well known public switched 
telephone network (PSTN) and lines 15A_and 20A are public telephone lines. Of 
course, other communications networks and lines may be used as desired. 

20 A telecommunications switch 32 (e.g. , a PBX) is in communication 

with telecommunications network 25 via line 32A. Telecommunications switch 32 
also is in communication with server 30 via line 30A and an interactive voice 
response unit ("IVRU") 34 via line 34A. IVRU 34 communicates with server 30 via 
line 34B. IVRU 34 provides an interface between server 30 and an account holder, 

25 allowing voice prompts to the account holder and transmitting signals received from 

10 
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the account holder to server 30, as will be further described below. 
Telecommunications switch 32, IVRU 34, and lines 30A, 32A, 34A, and 34B are 
well known and therefore are not described here further. See, for example, U.S. 
Patent No. 4,847,890, the disclosure of which is incorporated herein by reference. 

5 Server 30 includes one or more computers that are preferably located at 

one physical location. Alternatively, server 30 may include multiple computers that are 
connected via a network that spans multiple physical locations, thereby allowing the 
computers to communicate with each other via well known communication techniques. 
In this way, as is well known in the art, memory and processing may be distributed 

10 among the computers that may make up server 30. 

Server 30 is operated by or associated with an entity or organization 
(referred to as the "entity") that maintains data relating to account holders' credit card 
accounts. In the described embodiments, the entity is a credit card issuer. Of course, 
the entity may be a credit card processing company that operates a network for 

15 facilitating processing of credit card transactions, such as First Data Corporation. 

Telephone 35 is a telephone that is capable of generating Dual Tone 
Multi-Frequency ("DTMF") signals, and that is accessible by an account holder (or 
other designated person). Telephone 35 is in communication with telecommunications 
network 25 via line 3 5 A, which in this embodiment is a public telephone line. Of 

20 course, other communications devices may be readily substituted for telephone 35 as 
desired. 

It is noted that the foregoing hardware may include well-known internal 
connectors, architectures, interfaces, ports, and communication devices (e.g., modems) 
to enable processing and communication. For the purpose of simplicity and clarity, a 
25 detailed description of the same is omitted. 

11 
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Referring next to FIG. 2, a diagrammatic representation of an 
embodiment of server 30 is shown. Server 30 typically includes memory 1 10, and at 
least one processor 120 in communication therewith. Memory 110 typically includes 
one or more machine readable media. Such media include, as is well known in the art, 
5 - an appropriate combination of magnetic, semiconductor and optical media. Memory 
1 10 is preferably capable of supporting searching and storing of digital multimedia data 
such as text and audio. Memory 1 10 (or portions thereof) may reside on single 
computer, or may be distributed in a known manner among multiple computers that 
may be included in server 30. 

10 In the present embodiment, memory 110 includes credit card account 

database 200, merchant database 300, and user database 400. Transaction database 500 
may also be stored in memory 1 10 to provide additional functionality. Memory 110 
also stores program 600, which includes instructions for controlling processor 120 in 
accordance with the present invention, and particularly in accordance with the process 

15 described herein. 

The rows and columns of the databases described herein represent 
records and fields thereof, respectively. In the described embodiments, the databases 
are used in a relational arrangement, as is known in the art, so that the databases relate 
to one another by way of fields that store common data. It is noted that while the 

20 following description refers to specific individual databases, formats, records, and 
fields, those skilled in the art will readily appreciate that various modifications and 
substitutions may be made thereto without departing from the spirit and scope of the 
present invention. 

Referring now to FIG. 3, an embodiment of credit card account database 
25 200 is depicted in detail. Database 200 stores data relating to credit card accounts that 

12 
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are maintained for account holders. Each record (row) of database 200 represents such 
an account. For exemplary purposes, two records Rl and R2 are shown. 

Field 200A stores an account identifier that is associated with and that 
uniquely identifies a credit card account. In this embodiment, the account identifier is a 
5 sixteen digit credit card account number, such as is commonly imprinted on a credit 
card. Thus, as is well known, the first four digits of each account number indicate the 
issuer of the credit card. The remaining twelve digits of each account number are used 
to uniquely identify an account. Of course, other types of account identifiers may be 
used as desired. 

10 Field 200B may be used to store the name of an account holder. In one 

embodiment, the name stored in field 200B is a digital audio file (or a pointer thereto) 
that contains a pre-recorded audio sample of the account holder's name. Of course, an 
account holder's name may be stored in field 200B in another form, such as text. 

Field 200C may be used to store the address of an account holder. Fields 

1 5 200D and 200E may be used to store a credit line and available credit for an account, 
respectively. 

Referring next to FIG. 4, an embodiment of merchant database 300 is 
depicted in detail. Database 300 stores data relating to one or more merchants 10 with 
whom a user may execute transactions. One record (row) of database 300 is maintained 
20 for each merchant 10. For exemplary purposes, two records R3 and R4 are shown. 

Field 300A stores a merchant identifier that uniquely identifies a 
merchant 10. For exemplary purposes, the merchant identifier is shown as including 
five digits. 

Field 300B may be used to store a CAT identifier that identifies a 
25 particular CAT 1 5 of merchant 10. Field 300C stores a telephone number for a 

13 
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telephone 20 that is accessible by a user. In this embodiment, telephone 20 is located 
at the point-of-sale and is in close proximity to CAT 15 that is identified by the CAT 
identifier stored in field 300B. 



5 may be stored in the form of a digital audio file (or a pointer thereto) that contains a pre- 
recorded audio sample of the name of merchant 10. Of course, a merchant's name may 
be stored in field 300B in another form, such as text. 



in detail. Database 400 stores data that enables an account holder to communicate with 
10 a user to determine at least a portion of the circumstances surrounding a transaction that 
is being executed by the user. One record (row) of user database 400 is maintained for 
each credit card that is linked to a credit card account represented by a record in 
database 200. For exemplary purposes, two records R5 and R6 are shown. 



15 uniquely identifies a credit card that is linked to a credit card account represented by a 
record in database 200. In this embodiment, the identifier stored in field 400A is a 
sixteen digit credit card account number, such as the type commonly imprinted on a 
credit card. As will be described in more detail below, a user uses the credit card 
identified by the identifier stored in field 400A to execute a transaction with a merchant 

20 10. Field 400B stores an account identifier that is associated with and that uniquely 
identifies a credit card account to which the credit card identified by the user identifier 
stored in field 400A is linked. 



differ from the account identifier stored in field 200A so that the presentation of a user 
25 identifier would initiate transaction process 601 . Preferably, the length of the user 



Field 300D may be used to store a name of a merchant 10. The name 



Referring next to FIG. 5, an embodiment of user database 400 is depicted 



Field 400A stores a user identifier that is associated with and that 



In this embodiment, the user identifier stored in field 400A is made to 
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identifier is the industry standard length of sixteen digits. Of course, the user and 
account identifiers stored in fields 400A and 200A may be designed to be the same. In 
this case, field 400B would not be necessary. 



5 holder's account for each transaction initiated by the presentation of user identifier 

400A. The fee may be determined in a number of different ways. For example, the fee 
may be based on the amount of time that an account holder communicates with a user or 
it may be a fixed dollar amount that is charged to the balance each time that a credit 
card is used by a user. In another embodiment, the fee may be charged on a periodic 
10 basis — e.g., each year, regardless of the number of times that a credit card is used. In 
still another embodiment, the fee may be a percent of the transaction amount. In any of 
these embodiments, the fee also may be made to vary in accordance with the type of 
credit card. For example, if a credit card is a "gold" card, then a $25 annual fee may be 
charged. Alternatively, if a credit card is a "platinum" card, there may be no associated 



field 400D may be a digital audio file (or a pointer thereto) that contains a pre-recorded 
audio sample of the user's name. Alternatively, a user's name may be stored in field 
400D in another form, such as text. 



present embodiment, it is the telephone number of an account holder. In alternate 
embodiments, it may be a telephone number of another person, such as a relative of the 
user. 

Field 400F may be used to store a length of time (e.g., a number of 
25 minutes) that an attempt will be made to contact an account holder (or other person) at 



Field 400C stores a fee that is charged to the balance of the account 



fee. 



Field 400D may be used to store the name of a user. The name stored in 



Field 400E is used to store a telephone number of a telephone 35. In the 
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telephone 35 using the telephone number stored in field 400E. If this time elapses, a 
default command stored in field 400G may be executed. In one embodiment, the 
default command indicates whether a transaction should be authorized or declined in the 
event that the account holder (or other person) cannot be contacted. 
5 Figure 6 depicts, in detail, an embodiment of transaction database 500. 

Database 500 may be used to store data relating to transactions executed by a user using 
a credit card that is linked to an account stored in database 200. It may also be used to 
store data relating to conventional transactions involving other credit cards. For 
exemplary purposes, three records R7-R9 are shown. 
1 0 Field 500A is used to store either a user identifier or an account 

identifier. If a record represents a transaction between a user and merchant 1 0 in which 
a credit card that is linked to a credit card account represented by a record in database 
200 was used, then a user identifier stored in field 500A identifies that credit card, as 
described above with reference to field 400A (FIG. 5). Records R7 and R8 represent 
1 5 such records. If a record represents a transaction between an account holder and a 
merchant using another credit card, then the identifier stored in field 500A represents 
the credit card number of that credit card. Record R9 represents such a record. 

Field 500B stores an authorization code that is generated in a well- 
known manner by server 30 when it authorizes a transaction. Field 500C stores a 
20 record of charge identifier that is printed on a receipt and used to help the user and/or 
the account holder identify the transaction. The identifier stored in field 500C is 
generated by server 30 in a well known manner. Field 500D stores either a dollar 
amount spent by a user for a transaction or a fee that is to be charged to the credit card 
account, the latter of which is described with reference to field 400C (FIG. 5). 
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Field 500E may be used to indicate whether the value stored in field 
500D represents such a dollar amount or a fee. As shown in record R7, if the charge 
description stored in field 500E indicates a name of a merchant 10 (e.g., "ABC Drug 
Store"), then the amount stored in field 500D represents a transaction amount, here, 
5 $250.38. For example, as shown in record R8, if the charge description stored in field 
500E indicates "Emergency Card Usage Fee," then the amount stored in field 500D 
represents a fee — e.g., $20.00. Fields 500F and 500G store a merchant identifier and a 
CAT identifier, respectively, as described above with reference to field 3 00 A and 300B. 

It is noted that given a first record relating to a transaction, a second 

1 0 record relating to an associated fee may be determined. This is because the first and 
second records will have identical user identifiers stored in field 500A. Thus, for 
example, record R7 represents a transaction for "$250.38" and record R8 represents an 
associated "$20.00" usage fee. Consequently, both records R7 and R8 have the same 
user identifiers » i.e., "2222-3333-4141-5151." 

15 Referring again to FIG. 2, memory 110 also includes program 600. 

Program 600 comprises computer instructions and/or data, executable or otherwise, for 
performing the functionality of the present invention. FIGS. 7A and 7B depict process 
601 that may be embodied by such a program 600 for processing a credit card 
transaction and facilitating communication between first and second persons so that the 

20 first person may authorize a transaction between the second person and a merchant. 

Prior to execution of process 601 it is contemplated that an account 
holder and a user have been linked to a credit card account for which a record is 
maintained in database 200 (FIG. 3). This may be accomplished via a registration-type 
process whereby a user is registered with a credit card such that transactions executed 

25 with the credit card will affect the balance of the account holder's account. 
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At step 602, a user begins to execute a transaction with a merchant 10. 
To do this, the user presents a credit card that is linked to an account stored in database 
200(FIG 3)toamerchantl0forpayment. The credit card has an identifier impnnted 
thereon and/or encoded therein, which corresponds to a user identifier stored in field 

400 of database 400 (FIG. 5). 

Using conventional techniques, merchant 10 uses CAT 15 to transtmt a 
purchase authorization request to server 30 via line 15A, .^communications network 
25 line 32A, telecommunications switch 32, and line 30A (FIG. 1). In this 
embodiment, the request includes data indicating a purchase amount for the goods, an 
identifier ma, identifies the credit card ma, the user is using for payment, an .denffter 
ft* iden,ifics merchan. 10, and an iden.if.er ma, identifies CAT 1 5 ftom which a 
purchase authorization request is being transmuted. The purchase authorization reques, 
may be routed through a credi, ctud processing network (no, shown) to server 30 m a 
well known manner. Server 30 receives the purchase authorization reques, ftom CAT 

15 15. 

A, step 604, processor 120 of server 30 accesses the record ,n user 
database 400 whose field 400A corresponds ,o me identifier ma, identifies the credit 

■ a ,.,.„(M7 Processor 120 retrieves the account idenbfier stored 
card that was received a, step 602. processor 

i„ fie!d 400B for the accessed record. Processor 120 accesses the record in credi, card 
20 accoun,dambase200formereftievedaccoun,identtficrandre«ievesmeavailable 

credi, stored in field 200E. At step 606, if the available credit stored in field 20OE ,s 
determined to be less man the purchase amount received a, step 602, men the 
transaction is terminated a, step 608 and process 601 is complete. 

If the available credit stored in field 200E is determined a, step 606 to be 
greater or equal ,0 the purchase amount received a, step 602, then processing continues. 
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At step 610, processor 120 retrieves the name of the user and the account holder's 
telephone number from fields 400D and 400E, respectively, for the record in user 
database 400 that was accessed at step 604. Processor 120 also retrieves the name of the 
account holder from field 200B for the record in credit card account database 200 that 
5 was accessed at step 604. 

An inquiry is made whether the account holder desires to communicate 
with the user. In this embodiment, at step 612, the telephone number retrieved at step 
610 is used by IVRU 34, under control of processor 120 and telecommunications switch 
32, to attempt to connect the account holder. Thus, IVRU 34 places a telephone call to 

10 telephone 35 using that telephone number in a conventional manner. 

At step 614, it is determined whether the account holder has been 
contacted. If the account holder has not been contacted, then a feature of the present 
invention may be executed at step 616. In accordance with this feature, if the account 
holder cannot be contacted within the period of time specified in field 400F for the 

15 record in user database 400 accessed at step 604, then the default command stored in 
field 400G for that record is retrieved and executed. Thus, if the retrieved default 
command is "AUTHORIZE," then processor 120 will authorize the transaction in a 
conventional manner. Alternatively, if the retrieved default command is "DECLINE," 
then processor 120 will decline the transaction in a conventional manner. If this feature 

20 is not included and the account holder cannot be contacted, then the transaction may be 
terminated. If it is determined at step 614 that the account holder has been contacted, 
then at step 618 processor 120 instructs IVRU 34 to present a list of options to the 
account holder. For example, IVRU 34 may cause the following message to be played 
to the account holder: "Hello Mr. Johnson , you have a transaction authorization request 

25 from Joe Smith for $250.38 at ABC Drug Store . Press 1 if you wish to authorize this 
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taction. Press 2 if you wish .odecline tiris transaction. Press 3 if you wish ,0 talk 
with JocSnug," The underlined text may be played by IVRU 34 to the aecoun. hoider 
by accessing the relevant voice flies, or outer data in the ease of a monetary amount, . 
the appropriate databases. The account holder responds by depressing me number ■ V 
5 -2 " or "3" on the keypad of telephone 35 and a signal indicative of the response ts 
^ned » server 30 in a conventional manner. In an alternate embodiment, me Irs. 
of options may be presented to the account bolder by a human operator. 

At step 620, processor 120 determines whether the account holder 
desires to communicate with the user. If processor 120 received a signal indicating that 
,0 me user depressed the number » 1- or T on his keypad, men the account holder does 
no. desire to communicate with me user and processing continues at step 622. 

If processor 120 received a signal indicating that the user depressed the 
number "3" on his keypad, then the account holder does desire to commumcate with the 
user in mis case, a. step 624, processor 120 enables or initiates communication 
,5 beweenmeaccountholderandmeuser. In mis embodiment, processor .20 accesses 
Ae record in merchant database 300 whose field 300B corresponds to the CAT 
identifier that was include in the purchase authorization request received at step 602. 
Processor 120 retrieves me te.ephone number stored in fie.d 30OC for ma, record. 

The retrieved telephone number is used by IVRU 34, under control of 
20 processor 120 and telecommunications switch 32, to place a telephone can to the user a. 
telephone 20 in the proximity of CAT 15. The method and apparatus disclosed m U.S. 
Paten. No. 5,319,701 , incorporamd herein by reference, may be used to estabbsh 
connection berween .elephone 35 and telephone 20 so ma. the accoun. holder may 
communicate with me user before authorizing or declining the transaction a. s.ep 622. 
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The account holder and the user may communicate to discuss the 
circumstances surrounding the transaction. For example, consider an account holder 
who has a parental relationship with the user. Further consider that the parent permitted 
the child to use the credit card only in cases of emergency. In such an instance, the 
5 parent and child may communicate to discuss the nature of the emergency. In one 

embodiment, processor 120 is configured to track the duration of the communication so 
that a fee can be charged to the financial account based on the duration. 

At step 622, based on the communication, the account holder can 
authorize or decline the transaction using telephone 35. To do so, the account holder 

10 depresses the number " 1" or "2" on the keypad of telephone 35. A signal indicative of 
that response is transmitted to server 30 in a conventional manner at which point the 
command is executed. In an alternate embodiment, the account holder may enter a 
personal identification number via the keypad of telephone 35 in order to authorize or 
decline the transaction. In this case, the signal transmitted to server 30 comprises a 

15 personal identification number. At step 626, processor 120 continues processing the 
transaction in accordance with the response of the account holder at step 618 or 624. 
Thus, if the account holder authorized the transaction, then an authorization code is 
generated in a conventional manner, which is transmitted to CAT 15 that communicated 
the purchased authorization request to server 30 at step 602. The transaction database 

20 500 is updated as follows: the identifier identifying the credit card, the purchase 

amount, the identifier identifying the merchant, and the CAT identifier received in the 
purchase authorization request at step 602 are stored in fields 500A, 500D, 500F, and 
500G, respectively. 

An authorization code is generated and stored in field 500B. The record 

25 charge identifier is stored in field 500C. The charge description is obtained from the 
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15 



iden.if.er received in .he purchase authorization request received a, step 602. 

At step 628, a record is also populated in the tta.sac.ion database 500 to 
reflect the emergency charge. More specifically, the identifier identifying the credt, 
eard the identifier identifying the merchant, and the CAT identifier received . the 
purchase auurorization request at step 602 are stored in fields 500A, 500F, and 500G, 
respective,,. Tne transaction usage fee is obtained from user database 400 and is stored 
inf ,e,d500D. An authorization code is generated and stored in fie.d 500B. Therecord 
charge identifier is stored in fie.d 500C. The charge description "Emergency Card 
Usage Fee" is stored in field 500E. Process 601 ends at step 630. 

,„ an alternate embodiment, commnmcatton with merchant 10 may be 
terminated prior to accessing database 400 a, step 610 » determine tire telephone 
number of the account holder, to this way. processor 120 of server 30 ma, recede a 
signal from an account ho.der indicting whether to authorize the transaction. When 
„ signa, indicates tha, the transaction is „ be authorized, processor .20 of server 30 
ma y re-establish cotnntunication win. merchant 10 and transmit an authorization code 
thereto. Aecordhtgto another embodiment ofthis invention, if the account holder has 
uo. been contacted at step 6,2, titen pressor 120 ma, insttuc, ,VRU 34, under contro, 
of processor 120 and te.ecommnnications switch 32, to attempt to contact another 
, person(e.g.,are,ativeof*euser)whocanauti 1 orizeordec,ineti,ettansac,io, Also, 

me othet person may be sdected from among severe, peop,e depending on the time o, 
day that me data identifying the financial account and tite third party is received, to 
this case, user database 400 may be modified in a we„ known mannet ,o include me 
name(s) and ,e,ephone number(s) of each person, as we,, as the time of day that a 
person is to be contacted if this ,atter embodiment is imp,emen,ed. Each person may be 
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contacted as described above with reference to the account holder and processing would 
proceed as if the person was the account holder. 

In view of the foregoing, the present invention provides a method and 
apparatus in which an account holder can remotely control the authorization or denial of 
5 a card-based transaction executed by a user. The method and system enable the 

account holder to communicate with the user who is using a credit card to execute the 
transaction with a merchant. In this way, the account holder and the user can discuss 
the circumstances surrounding the transaction and the account holder can authorize or 
decline the transaction based those circumstances. Thus, the account holder is able to 

10 adequately control and manage charges made by users using credit cards that are 
linked to their accounts. 

While the foregoing embodiments have been described with reference to 
a credit card and corresponding credit card account, it is contemplated that other types 
of cards and financial accounts may be used. Such financial cards may include, for 

1 5 example, debit cards and smart cards and their associated financial accounts. 

To illustrate still other alternate embodiments, consider that control of 
cash withdrawal at an Automatic Teller Machine (ATM) can be remotely authorized by 
the account holder upon presentation of the user identifier 400A at the ATM. In this 
embodiment, the communication between the account holder and the user can be 

20 facilitated using audio and/or video transmission. In an audio-based embodiment, 

communication may be facilitated using the above-referenced telephone connections. In 
a video-based embodiment, communication may be facilitated between a personal 
computer of video phone connected to the ATM network and the ATM. In this video 
embodiment, video images of the parties may be input through video cameras and 

25 transferred during the communication. The personal computer may use well known 
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use 



video cameras, such as .hose common,, —tore hy In*. Corp. The ATM may 

im a E eof,heuser onthe somen of the accoun. h„.de,s persona, compu.er during dre 
morion ,o ensure rhat fire user presenting a card havurg user .denfificafion number 

5 400A is in fact authorized. 

Thus, aUhoughfire particular embodiments shown and described above 

are useful in many app.ioa.ions re.a,i„g » *e arts to which me preaen. mvendon 

person s W .,ed in me art. All such modif.ca.ions are deemed ,0 be wrthm me scope and 
10 spirit of me present invention as defined by me appended claims. 
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We claim: 



1. 



A method for facilitating communication between first and second 



persons so that the first person may authorize a transaction between the second person 
and a third party, wherein the method comprises the steps of: 



for the transaction; 

receiving data from the third party identifying the financial account and 
the third party; 

inquiring whether the first person desires to communicate with the 
10 second person based on the data identifying the financial account; 

receiving a response to the inquiry from the first person; and 
initiating communication between the first and second persons based on 

the response . 



5 



linking the first and second persons to a financial account that is used 



2. 



The method of Claim 1, further comprising the steps of: 



15 



receiving a signal from the first person indicating whether or not to 



authorize the transaction; and 



processing the transaction based on the signal. 



3. 



The method of Claim 2, wherein the signal indicates a personal 



identification number. 
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4 The method of Claim 1 , wherein the step of inquiring comprises the 
steps of accessing a voice file stored in a memory and causing an IVRO to play the 
voice file to the first person. 

5 The method of Claim 1. wherein the communication between the first 
5 and second persons has a duration associated therewith, and wherein the method 
^her comprises the step of charging a monetary amount to the financial account 
based on the duration associated with the communication. 

6. The method of Claim 1, further comprising selecting the first person 
from a plurality of persons . 

10 7 The method of Claim 1, further comprising selecting the first person 

from a plurafity of persons depending on the time of day mat the data identifying me 
financial account and the third party is received. 

8 The method of Claim 1, further comprising when a response to the 
taptiry is no. received from the firs, person within a predetermined period of time, 
,5 accessing a memory .o de«ermine whether me paction is «o he authorized or 
declined. 
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9. 



A method for facilitating communication between first and second 



persons so that the first person may authorize a transaction between the second person 
and a third party, wherein the method comprises the steps of: 

linking the first and second persons to a financial account that is used 
5 for the transaction; 

receiving data identifying the financial account and the third party from 
the third party; 

accessing a database based on the data identifying the financial account 
to determine a telephone number of the first person; 
1 0 placing a telephone call to the first person based on the telephone 

number thereof; 

inquiring whether the first person desires to communicate with the 
second person; and 

in response to an affirmative answer to the inquiry of the first person, 
15 accessing a database based on the data identifying the third party to determine a 
telephone number thereof; and 

enabling telephonic communication between the first and second 
persons using the telephone number of the third party. 



20 



10. The method of Claim 9, further comprising the steps of: 

receiving a signal from the first person indicating whether to authorize 



the transaction; and 



processing the transaction based on the signal. 
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11. The method of Claim 10, wherein the signal comprises a personal 
identification number. 

12. The method of Claim 9, wherein the step of inquiring comprises the 
steps of accessing a voice file stored in a memory and causing an IVRU to play the 

5 voice file to the first person. 

13 . The method of Claim 9, wherein the communication between the first 
and second persons has a duration associated therewith, and wherein the method 
further comprises the step of charging a monetary amount to the financial account 
based on the duration associated with the communication. 



10 



14. The method of Claim 9, further comprising selecting the first person 
from a plurality of persons. 

15 . The method of Claim 9, further comprising selecting the first person 
from a plurality of persons depending on the time of day that the data identifying the 
financial account and the third party is received. 
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16. A method for facilitating communication between an account holder 
and a user so that the account holder may authorize a card-based transaction between 
the user and a merchant, comprising the steps of: 

linking the account holder and the user to a financial account associated 
5 with the card that is used for the transaction, wherein the financial account is 
identified by an account number; 

communicating with the third party to receive the account number and 
data identifying the third party; 

accessing a first database based on the account number to determine a 
10 telephone number of the first person; 

attempting to contact the first person using the telephone number 

thereof; 

when the attempt to contact the first person is successful, 

inquiring whether the first person desires to communicate with 

15 the second person; 

in response to an affirmative answer to the inquiry, accessing a 
second database based on the data identifying the third party to determine a telephone 
number thereof; and 

enabling telephonic communication between the first and second 
20 persons using the telephone number of the third party. 

17. The method of Claim 16, further comprising the steps of: 
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receiving a signal from the first person indicating whether or not to 
authorize the transaction; and 

processing the transaction based on the signal. 

18. The method of Claim 16, further comprising the steps of: 

5 terminating communication with the third party prior to the step of 

accessing the first database; 

receiving a signal from the first person indicating whether to authorize 
the transaction; and 

when the signal indicates that the transaction is to be authorized, 
10 transmitting an authorization code to the third party. 

19. The method of Claim 16, wherein when the attempt to contact the first 
person is not successful, the method further comprises the steps of: 

accessing a database based on the account number to determine a 
telephone number of a subsequent person; 
15 placing a telephone call to the subsequent person based on the 

telephone number thereof and inquiring whether the subsequent person desires to 
communicate with the second person; 

in response to an affirmative answer to the inquiry from the subsequent 
person, accessing a database based on the data identifying the third party to determine 
20 a telephone number thereof; and 

enabling telephonic communication between the subsequent and second 
persons using the telephone number of the third party. 
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20. An apparatus for facilitating communication between a first person at a 
first location and a second person at a point-of-sale location so that the first person 
may authorize a transaction between the second person and a third party at the point- 
of-sale location, wherein the first and second persons are linked to a financial account 
5 used for the transaction, and wherein the system comprises: 

a memory storing data identifying the financial account and the third 
party, a first telephone number associated with the first location, and a second 
telephone number associated with the point-of-sale location; and 

a processor in communication with the memory, wherein the processor 
10 is adapted and configured to 

receive from the third party data identifying the financial 
account and the third party from the third party, 

access the memory based on the data identifying the financial 
account and the third party to determine the first and second telephone numbers, 
1 5 transmit instructions to contact the first person based on the first 

telephone number, 

inquire whether the first person desires to communicate with the 

second person, and 

enable communication between the first and second persons 
20 based on a response to the inquiry and the second telephone number. 
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21. The apparatus of Claim 20, further comprising a device in 
communication with the processor, wherein the device is adapted and configured to 
receive the instructions, contact the first person based on the first telephone number, 
and inquire whether the first person desires to communicate with the second person. 

5 22. The apparatus of Claim 21, wherein the device is further adapted and 

configured to receive a response from the first person and transmit the response to the 
processor. 

23. The apparatus of Claim 21, wherein the device comprises an IVRU. 
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